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FIELD OF TH E INVFNTiniv 

This invention relates ,o commnnieations on mobile devtee, More specifically i, 
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BACKGRO UND OF THF INVENTION 

Mobile devices such as mobile phones, personal digital/data assistants, ("PDA"), 
two-way pagers, etc. are relatively inexpensive, have become commonplace, and are 
5 available to most consumers. These mobile network devices can be wireless or wired 
mobile devices. 

Such mobile devices are typically limited ,„ small physical size, light weights and 
corresponding small display screen size, These mobile devices have a number of 
constraints including limited processing power, limited memory, hmited battery Ufe, a 
10 limited number of buttons on a user interface, etc. 

The larger a processor in a mobile device, the larger the size and weight the 
device will be. The more memory in a device the more expense it will be. Faster 
processors, more memory and color displays consume more battery power. 

Content and service providers who provide content and services via mobile 
.5 devrces have to balance the physical constraints of such mobile devices along with the 
ability to provide applications and content that consumers actually wan,, and are willing 
to pay for. The content and services have to be provided to mobtle devices in a format 
that is usable on the mob.le device and have to be provided quick* si „ ce most use, of 
mobile devices pay for content and services by the minute. 

There are relatively few applications ma, have been created ,„ be used on mobile 
devices tha, provide content in a forma, useable on the mobi.e device, The appl.cations 
■ha, do exist include text-based micro-browsers for delivering real-time stock quote, 
access to news, sports scores, weather forecasts, text-based electronic commerce 
applications and other types of text-based applications. 



McDonnell Boehnen 

Hulbert & Berghoff 
300 South Wacker Drive 
Chicago 1L, 60606 
(312) 913-0001 



There are a number of problems associated with developing applications for 
mobile devices. One problem is that virtually every mobile device has a unique hardware 
platform. An application written for one mobile device hardware platform won't work on 
another hardware platform for another mobile device. 
5 To help overcome this problem for devices in general, Sun Microsystems of 

Mountain View, California, developed the Java programming language. Java is a high- 
level programming language that was designed to be platform-neutral (i.e., it can be run 
on virtually any hardware platform). Java programs are compiled into byte-code and run 
in a special software environment known as a "virtual machine." This and other 
10 characteristics of Java make it a useful language for programming a large number of 
different types of applications for mobile devices. Java is typically used for 
programming small applications, called Java "applets." 

When Java applets are downloaded onto a device they are executed by a Java 
virtual machine in a secure "sandbox." A sandbox is Java virtual machine security area 
15 for downloaded (i.e., remote or untrusted) applets. The sandbox is an area in which such 
applets are confined and prevented from accessing certain data and resources (e.g., 
system resources and data). Confinement to the sandbox prevents downloaded applets 
from carrying out potentially dangerous or malicious operations on the device. Applets 
have to "play" inside the sandbox, and any attempt to "escape" is thwarted by a Java 
20 security manager. 

However, the full version of the Java programming language was too large to be 
used on mobile devices with constrained resources. When Sun Microsystems developed 
the second version of Java, it was split into three editions. The three editions include 
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micro version, Java 2 Micro Edition t"J2MR"t r 

( J2ME ) for small mobile devices> a standard 

^ ,a -^H dWo „ C , 2SnfordBWoporotei ^ devices>mdan 

^^.^ 2E n tnpris e MMonC , 2EE , formuIti . fe 
applications. 

^--- hlghl a tency , networkmtyTheCLDc 
cann m(h ea PpI i catlonacrossdifferenthadwarepiaifonnsandM ^ te 

Application Programming Interfaces ("A Pn ,u . 
,5 J2MEa r • S(API,,ha,proV * s ftenm,imeenvi romil e„, for 
J2ME applications using the CLDC. TheMIDP m 

he MIDP manages applications, user interfaces 
networking and inpnt/output for the mobile device. 

— '«amo re comp,e X app,i C atio„,oamoh„e d ev,ce 
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specific applications (e.g., new ring tones, new fonts, new graphical look-and-feel, etc.) 
and many other types of applications. 

There are a number of problems associated with using MIDlets and MIDlet Suites 
on a mobile device. One problem is that for security reasons, one MIDlet Suite cannot 
5 launch another MIDlet Suite (i.e., act as its handler). Since the CLDC and MIDP does 
not define or use a Java security manager (i.e., a security manager is typically too big and 
complex for small devices), the interactions of MIDlets is limited to MIDlets packaged 
together in the same MIDlet Suite. However, the MIDP specification does not explicitly 
prohibit one MIDlet Suite from launching another MIDlet Suite. 
10 Another problem is that a MIDlet in a one MIDlet Suite cannot accept input data 

from, or cannot provide output data to, another MIDlet in another MIDlet Suite because a 
MIDlet Suite is executed in its own sandbox. This limits the type of MIDlet applications 
that can be created for a mobile device and prevents the ability to allow interaction 
between MIDlets or MIDlet Suites that have already been created. Another problem is 
15 that a MIDlet Suite cannot accept input data from, or provide output data to other 
applications on the mobile device (i.e., non-MIDlet applications). 

Thus, it is desirable to allow a J2ME MIDlet in a MIDlet Suite to accept data 
from, and provide data to, other MIDlets in other MIDlet Suites on a mobile device. It is 
also desirable to allow a MIDlet to accept data from, and provide data to, other non- 
20 MIDlet applications on a mobile device. 



6 

McDonnell Boehncn 

Hulbert & BcrghofT 
300 South Wacker Drive 
Chicago 1L, 60606 
(312)913.0001 



SUMMARY OF THE INVENTION 

In accordance with preferred embodiments of the present invention, some of the 
problems associated with using J2ME MIDlets on mobile device are overcome. A 
method and system for accessing a universal message handler on a mobile information 
5 device is presented. 

One aspect of the invention includes an object-oriented application program 
interface including a one or more object-oriented object classes to allow input and output 
data to be communicated between J2ME MIDlets in different MIDlet Suites and between 
MIDlets and non-MIDlet applications. The application program interface may be used to 
10 allow applications to access a universal message handler executing on the mobile 
information device. 

The foregoing and other features and advantages of embodiments of the present 
invention will be more readily apparent from the following detailed description. The 
detailed description proceeds with references to the accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present inventions are described with reference to 
the following drawings, wherein: 

FIG. 1 is a block diagram illustrating an exemplary wireless network system; 

FIG. 2 is a block diagram illustrating an exemplary J2ME architecture; 

FIG. 3 is a block diagram illustrating further details of the exemplary J2ME 
architecture of FIG. 2; 

FIG. 4 is a block diagram illustrating an exemplary J2ME architecture for a 
mobile information device 12. 

FIG. 5 is a block diagram illustrating an exemplary loading of a J2ME MIDlet 
onto a mobile information device; 

FIG. 6 is a block diagram illustrating states in a MIDlet life cycle; 

FIG. 7 illustrates an exemplary utility application programming interface; 

FIG. 8 is a flow diagram illustrating method for exchanging output data between 
portable applications on a mobile information device; 

FIG. 9 is a flow diagram illustrating a method for using input data on portable 
applications on a mobile information device; 

FIG. 10 is a flow diagram illustrating a method for invoking a MIDlet as a MIDlet 
handler; 

FIG. 1 1 is a block diagram illustrating an exemplary operation of an application 
management system; 

FIG. 12 is a flowchart of an exemplary process for an application management 
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m m ,„ rec e ive input data from an applicat . OT md tQ ^ ^ , nput (o a ^ ^ 

MIDlet in a first Java MIDlet suite; 

FIG. ,3 is a flowchart of an exemplary process for an appneata management 

5 the input data to an application; 

FIG. 1 4 is a flowchart of an exempt process for an app,ica,io„ management 
astern ,„ pass ou(put data belwee „ ^ § ^ ^ 

FIG. ,5 is a flowchart of an exempiary process for an app,ica,ion management 
system ,o exchange data between applications on a mobi.e infonnatton device; 

FIG. 16 isa flowchart of an exempt process for an apphc*,io„ management 

device; 

FIG. , 7 is a block diagram illustrating an exempiary operation of me applicahon 
management system pnsh launching an app.ica.ion with context on the mobile 
15 information device; 

FIG. .8 is a flowchart of an exemplary process for an application management 
system pnsh ,an„chi„g an application with context on a mobile informal device; 

FIG. , 9 is a flowchart of an exemplary process f„ r m applicalion mmgmt 
system on a mobile information device handling a push message; 

FIG. 20 is a block dtagram illustrating an exemplaty operation for a Java MIDlet 
executing on a mobile mformat.on device to access the umversa, message handler; 
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FIG. 2, is a flowchart of an exempt process fo, the appiication management 
system ,o allow an instant messaglng app|icatio „ ^ ^ ^ 

device to access the universal message handler; 

FIG. 22 is a flowchart of an exemplary process for a Java MIDlet executing on a 
mobile information device to access the universal message handler; and 

FIG. 23 is a flowchart of an exenrpiary process for the universal message handier 
to gran, access to a Java MJMet executing „„ a mobile infonnation device. 
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DETAILED l»«T»lrTION n[r 
PREFFRRt'n i, ^P QDiMEiVTi 

EXEMPLAR V w, P1J , „„. r , rTWOB „ gvCTr ,,. 

FIG. . is a block diag™ illustrating m eMmplary w . e]ess Mtwork ^ 
Wireless ncwo* system 10 includes plural mobile infomation ^ ^ ^ 

— ' * and an information network JQ ^ ^ ^ ^ ^ ^ ^ 
•o mese components m d more , fewer or ^ ^ ^ ^ ^ ^ ^ 

■0 netw OTksysteml0 . Po r s Imp , lcity , onlyonewire|essgateway]4>databasei6and 
database server 18 is illustrated in FIG. 1 . 

The mobile infection devices ,2 i„ clu de mobile phones IT, persona, 
d—a assistants ("PDA") 12", one and two-way pagers ,2" and other ,vp es of 
wreless mobile and non-mobile mformation devices (no, illustrated) . 

The wtata gateways .4 provides a code division mu„ ip ,e access ("CDMA"), 
Wideband CDMA f"\\rrr\**A 

( WCDMA ), Time Division-Synchronous CDMA ("TD-SCDMA") 

Advanced Mobile Phone Service («AMK"i m , 

rvice ( AMPS ), Digital AMPS ("D-AMPS"), Universal 

Mobile Telecommunications System ("UMTS"! R«Hi„ it 

m t UM 1 s ), Rad, 0 Frequency ("RF"), pa gi ng mi 

wireless messaging, Packet Cellu|ar ^ ^ ^ ^ ^ ^ 
- Communications, CGSM",, Generic Packet Radio ^ ^ ^ 

Communications Services ("PCS",, Cellular Digita, Packet Data f , CDpD „ ) ^ 
Application Protocol ("WAP,, Digital Audio Broadcasting ("DAB"), B,ue,oo,h 
«^*"*-**^^ fctol-||l|l(llllitafciiii 
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Further information on these wireless interfaces may be found in their respective 
standards documents. CDMA, for example, is described in further detail in 
Telecommunications Industry Association ("TIA") standards IS-95 A and IS-95B, which 
are both incorporated herein by reference in their entirety. CDMA is also described in 
5 the International Telecommunications Union ("ITU") IMT-2000 series of standards, 
which are all incorporated herein by reference in their entirety. CDMA is further 
described in the TIA IS-2000 series of standards, which are all incorporated herein by 
reference in their entirety. The IS-2000 series of standards are commonly referred to as 
CDMA2000. 

10 The WAP includes several protocols and standards designed to provide wireless 

devices with access to electronic content, and it was developed as an alternative to other 
markup languages and protocols developed for the World- Wide- Web. One component of 
the WAP is a Wireless Markup Language ("WML"), which includes markup tags, and 
provides control over formatting and layout of electronic content. The WML is often 

15 more appropriate to use for wireless devices such as wireless phones than other markup 
languages such as Hyper Text Markup Language ("HTML"), etc. 

The databases 16 include electronic content such as text, hypertext, graphical data 
or references to graphical data images, audio, video and other content. The electronic 
content may be stored as a Web page or WAP page on a database server 18. The 

20 database server downloads or "serves" electronic content from the database 16 to the 
mobile information device. 

A hypertext document includes markup codes called "tags." The structure of 
hypertext documents is defined by document markup languages such as Hand Held 
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Dev.ee Ma*up Lan^e ("HDML"), HTML, compact HTML ("cHTML"), eXtenaibfe 



electronic data. 



' content 
• other 



Electronic con,., is t¥pically djsp|ayed , ^ ^ ^ 

software application called a "browser." A browser on a mobile information device 12 

m a y beas U b.se,o f a,ar g erbr„wser,ora m icro,rowse, Ami c ro - browserraaynotbe 
-P* of d 1S p,aym 8 complete comem of a r „ eiectron;c conKnt ^ ^ m 

^^^^—^—apwea.attintauo n, audio, video, e ,e f„ r 
display on the mobile information device 1 2. 

The information network 2 „ indudes ^ te WorH _ wide Web ^ 
■nlranet, or other information nelwor, As is ^ in fc ^ fc ^ . , ^ 

- -enetworUfmterconnectedcompote, The World-W,de-Web is an ^ 
system on the Interne, designed for electronic content in t e rcllange . 

on shards p ropc . se d by the htstitn.e of Electnca, and Electronic Engineers ("IEEE") 

20 ( ITU ), Internet Engineering Task Force f'TFTF". ur i * 

rorce ( IETF ), Wireless Application Protocol 

( ANSI"), or other standards. 
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IEEE standards can be found on the World Wide Web at the Universal Resource 
Locator ("URL") "www.ieee.org. " The ITU, (formerly known as the CCITT) standards 
can be found at the URL "www.itu.ch." IETF standards can be found at the URL 
"www.ietf.org." The WAP Forum standards can be found at the URL 
5 "www.wapforum.org." The Java Community standards can be found at the URL 
"java.sun.com." ANSI standards can be found at the URL "www.ansi.org." 

An operating environment for devices and interfaces used for the present 
invention include a processing system with one or more high speed Central Processing 
Unit(s) ("CPU"), or other types of processors, and a memory system. In accordance with 
10 the practices of persons skilled in the art of computer programming, the present invention 
is described below with reference to acts and symbolic representations of operations or 
instructions that are performed by the processing system, unless indicated otherwise. 
Such acts and operations or instructions are referred to as being "computer-executed," 
"CPU executed" or "processor executed." 

15 It will be appreciated that acts and symbolically represented operations or 

instructions include the manipulation of electrical signals by the CPU or processor. An 
electrical system represents data bits which cause a resulting transformation or reduction 
of the electrical signals, and the maintenance of data bits at memory locations in a 
memory system to thereby reconfigure or otherwise alter the CPU's or processor 

20 operation, as well as other processing of signals. The memory locations where data bits 
are maintained are physical locations that have particular electrical, magnetic, optical, or 
organic properties corresponding to the data bits. 

The data bits may also be maintained on a computer readable medium including 
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magnetic disks, optical disks, organic memory, and any other volatile (e.g., Random 
Access Memory ("RAM")) or non-volatile (e.g., Read-Only Memory ("ROM")) mass 
storage system readable by the CPU or processor. The computer readable medium 
includes cooperating or interconnected computer readable medium, which exist 
5 exclusively on the processing system or be distributed among multiple interconnected 
processing systems that may be local or remote to the processing system. 



JAVA 

As is known in the art, Java is an object-oriented programming language 
10 developed by Sun Microsystems of Mountain View, California. More information about 
Java can be found at the URL "java.sun.com. " Java is based on object-oriented 
programming techniques. As is known in the art, object-oriented programming is used to 
design computer software including object-oriented objects that are easy to create, cost 
effective to modify, and reusable. Object-oriented objects include "object data" and 
15 "object services." Object services are provided through "object methods" (also called 
"object operations" or "object functions"). Object methods typically operate on private 
data such as "instance data" or "object state data" that an object owns. A collection of 
objects is called an "object class" which is sometimes called an "object type." An object 
class acts as a template that describes the behavior of sets of objects. An object's 
20 implementation is typically encapsulated, and is hidden from public view. Object private 
instance data can only be accessed by object methods of an object class. Object public 
instance data is accessed through a public "object interface." 
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Java was designed to be platform-neutral (i.e., it can be run on virtually any 
hardware platform). Java programs are compiled into byte-code, which is not refined to 
the point of relying on platform-specific instructions. Java runs on a hardware device in a 
special software environment known as a "virtual machine." 

This characteristic of Java makes it a useful language for programming a large 
number of different types of mobile information device 12 applications. Java is typically 
used in programming small applications, called Java "applets." 

JAVA 2 PLATFORM MICRO EDITION 

The Java 2 Platform Micro Edition ("J2ME") is used to create applications for 
fixed and mobile wireless devices. J2ME is a subset of the Java 2 Platform Standard 
Edition ("J2SE"). More information about J2ME can be found at the URL 
"j ava. sun. com/j 2me. " 

J2ME includes two major elements: (1) configurations; and (2) profiles. J2ME 
configurations provide a set of libraries and a virtual machine for a category of wireless 
devices. A configuration is a specification that defines the minimum Java libraries and 
Java virtual machine capabilities for a mobile information device 12. A configuration is 
defined for classes of devices with similar memory requirements and processing power. 
J2ME configurations are defined for both fixed wireless devices and mobile wireless 
devices. 

J2ME profiles are built on top of configurations to provide a run-time 
environment for a specific device. J2ME profiles manage applications, user interfaces, 
networking, input/output and other functionality of a device. 
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F'G. 2 is a bio* diag™ illustrating exemp]aiy J2M£ arch . tecture ^ ^ 

" 3 ™* device 12 hardwm |ayer ^ a 

na.,veope raUngs , temlayer26 , aconfigraiion|ayer28taciudtagajarav ^ 

Machine 30 and Java Itbraries 32 and a profile lay er 34. 
' The mobile informal device ^ ^ in£|udes ^ ^ 

for the mobile information device 12 Th e „„,i„. 

The nattve operattng system layer 26 includes the 

nattve operating system being nsed on the mobile information device ,2 

The confix laye r 2 8 pr ov,des a Java Virhaa, Machine 30 The 

" — rt.aJVM, - ^ronmen, m which Java programs nm. ^ ^ , ves 
-aprogramsasonware-baseddevieerheycanm^^.^^^^^ 

■-Omaymclnde.K.oVirmalMachtncaCompactV.nalMachineoromerJava 
virtual machine. 

" , K "° "'^ MaCWM ( " KVM "' * « runtime environmem for 

-»mespeci„cdev ia , 1 o„s,ha, a re»ece S sary f or P roperm„c ti o„ingo„sma,,deviees I , 

estgmedforlargerconsamer.dembeddeddevtces. The CVM suppo„s a„ Jav a 2 
^»-,^i^„ lBW , taj]rt 
described and other J2ME, J a v a or other virtual machines may be used 
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Currently rhere are two widely used J2ME configurations 28 including the 
Connected Limited Device Configuration ("CLDC") and the Connected Device 
Configuration ("CDC"). 

The CLDC in the J2ME runtime environment targets small, resource-constrained 
' devices, such as mobile phones, persona, digital assistants, small retaj| „ 

tetminals, etc. Typically, these devices run on either a .6- or 32-bit CPU or processor 
and have 5,2 Kbytes or less memory ^ for ^ ^ ^ ^ 

The J2ME CLDC Specification, version 1 ,0a, JSR000030, is incomorated herein by 
reference. 

The CDC is designed fo, next-generation devices with more robust resources 
(eg., set-top boxes, i„-car entertainment devices, Interne, appliances etc.) Typically, 
these devices nm on a 32-bit CPU or processor and have two Mega-bytes ("Mbytes.) ot 
more memory available for the Java platform and applieatton, The J2ME CDC 
Spectfieation, version 1 .0, JSR000036, is incorporated herein by reference. 

Returning ,„ FIG. 2, the profile layer 34 may include a Mobile Interface Device 
Profile ("MIDP"), PDA profile, Foundation profile, Persona, profile, Remote Machine 
Invocation ("RMI") profile or other profile. 

uetworking, databases, and time,. The MIDP is typically used for wireless mobile 
Phones and two-way pagers. The I2ME MIDP Specificatton, version 1.0, ISR000037, is 
incotporated herein by reference. The PDA profile is also based on the CLDC. I, 

The I2ME PDA profile specificatton, ISR000075, is mcorporated herein by reference 
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The Foundation Profile extends the APIs provided by the CDC, but it does not 
provide any user interface APIs. The J2ME Foundation profile Specification, version 
1.0, JSR000046, is incorporated by reference. As the name "foundation" implies, the 
Foundation profile is meant to serve as a foundation for other profiles, such as the 
5 Personal profile and the RMI profile. 

The Personal profile extends the Foundation profile to provide Graphical User 
Interfaces ("GUIs") capable of running Java Web applets. The RMI profile extends the 
Foundation profile to provide Remote Method Invocation for devices. It is used with the 
CDC/Foundation profile. However, the Foundation profile is not currently used with 
10 CLDC/MIDP. The J2ME Personal profile specification, JSR000062, is incorporated 
herein by reference. 

FIG. 3 is a block diagram 36 illustrating further details of the exemplary J2ME 
architecture 22 of FIG. 2. In one variety, the J2ME architecture 36 configurations layer 
28 includes a KVM 38 and a CLDC 40 below a J2ME profile including a MIDP 42 or a 
15 PDA profile 44. In another variety, the J2ME architecture 36 includes a J2ME 

configuration 28 with a CVM 46 and a CDC 48 below a J2ME profile 34 including a 
foundation profile 50 below a RMI profile 52 or a Personal profile 54. These two J2ME 
varieties are used separately and are not used in the same device at the same time. 

J2ME applications that conform to the MIDP are called "MIDlets." A MIDlet, 
20 includes a public object class definition. This public object class includes object methods 
that have been inherited from the MIDlet class. MIDlets can be grouped together in a 
MIDlet Suite by creating a Java Archive ("JAR") file. An optional Java Application 
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Descriptor ("JAD") file may be used to describe the MIDIets that 
Suite. 



constitute the MIDlet 



MIDIets are the executable entities within the MIDlet Suite. The MIDlet Suite 
typically comprises: (1) Java class files enclosed in a JAR file; (2) a manifest file 
5 describing the contents of the JAR; and (3) resources (nnages, etc.) enclosed in a JAR 
file. A JAD file, which is technically not part of the MIDlet Suite, may be used in 
conjunction with the MIDlet suite. 

In addition ,o class and resonrce files, a JAR typically i„cl udes a manifest file that 
describes the contents of the JAR. The mantfcst file typ.cally is calIed . nmifeslmf ^ 
to is stored in the JAR file itself. Table , lists some exemplary attribntes that may be 
defined within the manifest fife i„ . JAR, The manifest file, however, may inclnde 
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ATTRIBUTE 

MIDIet-Name 

MIDIet-Version 


DESCRIPTION 

— 


MIDIet-Vendor 


Version number of the MIDlet. 


MIDIet-lcon " 


Who created the MIDlet. 




Icon associated to show alongside the MIDIet- 
Name by the application manager. This is a 
graphics file stored as a PNG image. 


MIDIet-Description " 

MIDIet-lnfo-URL " 


Text describing the MIDlet. 


MIDIet-<n> 


u!£i ? at T, ay have more infoi ™ation about the 
MIDlet and/or the vendor. 




This attribute contains up to three pieces of ~~ 
information: 

• MIDlet name 

• Icon for this MIDlet (optional) 

^' aS f £ ame the a PP' icati °n manager will call 
to load this MIDlet. 
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MIDIet-Jar-URL 


URL of the JAR file. 


MIDIet-Jar-Size 


The JAR file size in bytes. 


MIDIet-Data-Size 


The minimum number of bytes required for 
persistent data storage. 


MicroEdition-Profile 


What J2ME Profile is required by the MIDIet. 
(e.g., MIDP) 


MicroEdition-Configuration 


What J2ME Configuration is required by the 

MIDIet. 

(e.g., CLDC) 


Tab 


lei. 



Although not required, a JAR file may be used in conjunction with a JAD file. As 
with the manifest file, this file includes information about a MIDIet. The JAD provides 
information to an application manager about the contents of a JAR file. With this 
5 information, decisions can be made as to whether or not a MIDIet is suitable for running 
on the device. 

As an example, by looking at the attribute MIDIet-Data-Size, an application 
manager can determine if the MIDIet requires more persistent memory than the device 
can provide. The JAD provides means for parameters to be passed to a MIDIet without 
10 having to make changes to the JAR file. The JAD file can also use the same attributes as 
are listed Table 1. The JAD file, however, may use additional attributes, or it may omit 
some of the attributes listed in Table 1. Various types of MIDlets and MIDIet suites are 
created to provide functionality to mobile information devices 12. 

15 MOBILE INFORMATION DEVICE J2ME ARCHITECTURE 

FIG. 4 is a block diagram illustrating an exemplary specific J2ME architecture 56 
for a mobile information device 12. The architecture 56 includes a mobile information 
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ic content on 



dev,ce b.rdw.re la yer U, native operating sys , em , ayw 26> a configura(iM ^ 

28 .nc MngaJ2ME KVM3S m<i a J2 MEC L DC40,a, 2M E profiI e, ay e r32inclllding 
a J2ME MmP 4 2 , a Java Apphcation Manage, ("JAM") 58, .d one „ r more J2ME 
MJDlets in a MIDIet layer 60, and a micro-browser 62. 

In J2ME, the a Java Ap P „ca«i„„ Manager ("JAM") 58 is an app,ica ( ion t ha, 
■ncUrdes . se, of fnnctionaiity that down|oads ^ ^ (o ^ ^ 
information deviee , 2 from a informat ion network 2Q ^ ^ ^ 
«he device, and mana g es „ fecycles of ^ ^ ^ ^ ^ ^ 

10 Web and/or WAP servers 18. 

There a re many different methods for smiing ^ fr g _ ^ 
content ,o a mobUe informarion device 12 Ending cHTML, WML, HTML, XHTML or 

-tent is a,s„ generated in appbcation servers .nd Web servers, targeiy based nport 

•nfomtation extracted ^ a datable .d cap ab ,e of being modified dynamiea„y (e g 
»ng XML, Java a p pI e ts , J ava Servlets> ^ ^ ^ 

other server-side technologies). 

A wireiess gateway 14 typicaiiy distributes e.ectmnic content to the mobde 

,nfo™ a , i o„dev,ce 12 f rom aWeborWA Ps e™ 1 S.O„ee,bee,ec,ro„ i eeo„,e„„s 
— .o me mobrie informs device 12 , « is lypically rendered by , ^ ^ 



62. 
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IS 



Increasing,* Java applications, such as J2ME MID ,e t s te reside 0 „ a We „ 0f 
WAP server ,8 may be served through the informatio „ ^ 2Q ^ ^ 
devices .2 using the J2ME 56 „ ^ ^ ^ 

Mttlets are another type of electronic content Such MTOlets may inCude 
app.iea.ions for the ntohi.e in f onMtion device such „ ^ ^ ^ ^ ^ 
^-specific applications (e. g ., dy^e stock bamKr , ^ ^ ^ ^ ^ 
specific applications (e . g „ new ring ^ „ „ ^ ^ ^ ^ ^ ^ 
other types of applications. 



10 J2ME Mini..T PANSFFR PBnf . rcC[ 

Onee a MIDle, or MJDlet suite is created , 0 ^ , ^ ^ 
ready to be districted, it is , 0 aded onto the mobile information device , 2 „ y J2ME 
JAM 58. The MJDP specification specifies fta , , rf a ^ 

device must pmvide an application manager (e.g., J2ME JAM 58) built into the device 
15 that can load a J2ME MIDlet onto the device. 

FIG. 5 is a Mock diagram 64 illustrating an exempt loadtng of a MIDlet onto a 
«** information device. A user of a mobile infection device 12 visits a Weh page 
(or WAP page, u stored on a Web or WAp ^ ^ ^ ^ 

The page lists MJDlets 68 (or MfD.et Suites, tha, are available for purchase a„ d 
20 download. 

As was bussed above individual MDlets can be grouped together in a MIDlet 
Sutle by creating JAR ffle 70 and an accompanying J AD file 72. The J AD file 72 

includes information about the MIDlet annhcation 68 rr 

ici application 68. For example, the JAD file 72 
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may include a version for the MIDlet application, a size of the MIDlet application, or 
other types of information. 

If the mobile information device 12 already has the same version of the MIDlet 
68, a user of the mobile information device 12 can be alerted to this fact so he/she doesn't 
5 buy it again. The JAR file 70 can also include the size of the actual MIDlet 68, so that if 
the mobile information device 12 only has 2K of space left and the MIDlet 68 is 6K in 
size, it can pop up a window saying that the device doesn't have enough room to 
download and store this MIDlet 68. 

Once the user is ready to download the application 74 and the J2ME JAM 58 has 
10 confirmed that there is enough space, the JAM 58 downloads 76 the MIDlet 68. The 

JAM 58 typically displays the download status 78. The JAM 58 will save the MIDlet 68 
on the device and then present it as a selection so that the user can launch and use the 
MIDlet. 



15 MIDlet EXECUTION 

When a MIDlet is launched, the MIDlet enters the KVM 38 and life cycle 
methods of the MIDlet are invoked. Each MIDlet has a life cycle with a distinct series of 
states. The state of a MIDlet is controlled by the JAM 58 based on user interaction (e.g., 
key presses, etc.) or program-based notification (e.g., messages, time-outs). 
20 FIG. 6 is a block diagram 80 illustrating states in a MIDlet life cycle. The MIDlet 

life cycle states include the paused state 82, the active state 84, and the destroyed state 
86. Transitions from one state to another are defined by the J2ME MIDlet class as 
abstract methods. Table 2 illustrates exemplary abstract methods for MIDlet states. 
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// Sample MIDlet 

public class Sample extends MIDlet { 
public Sample () { 

} 

public void startAppO throws MIDletStateChangeException { 

} 

public void pauseAppO { 

} 

public void destroyApp (boolean unconditional) { 

} 



Table 2. 



Table 3 illustrates the MIDlet states and their corresponding description. 



MIDlet State 


Description 


rnUOLU 


Tho IMiniot ic in itiali"7oH anH ic miiocfont It 
1 lie; IVIIL/id lo II 1 1 lldl l^-CU gIIU to LjUltJoOCIIl. 11 

should not be holding or using any shared 
resources. This state is entered: 

(1) After the MIDlet has been created using 
MIDIet.new( ). The public no-argument 
constructor for the MIDlet is called and returns 
without throwing an exception. The application 
typically does little or no initialization in this 
step. If an exception occurs, the application 
immediately enters the Destroyed state and is 
discarded; 

(2) From the Active state after the 
MIDIet.pauseApp() method returns 
successfully; 

(3) From the Active state when the 
MIDIet.notifyPaused() method returns 
successfully to the MIDlet; and 

(4) From the Active state when the startApp( ) 
method throws a MIDlet state 

change exception. 


ACTIVE 


The MIDlet is functioning normally. This state is 
entered just prior to calling the 
MIDIet.startAppQ method. 
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DESTROYED 



argument is falsa and a MIOIel slate chanae 
(2) When the MIDIet.notifyDestroyedO methnH 
; ablel — 



An exemplary MIDlet is shown in Table 

message in each oftheMlDlet states. 
^^P^Hiv^n^ 

IS!m" 0U ! Print ' n( " Hel, ° Fro ™ J2ME MIDlet 
System.out.prmtlnf In ACTIVE STATE "V 
pauseApp(); vcol «it...), 



4- This exemplary MIDlet prints; 



); //ACTIVE STATE 



public void pauseApp( ) { 



public void destroyApp( boolean 
bystem.out.print!n( "In Dl 

} // End PrintStateMIDIet 



DESTROYED STATE 



Table 4. 

In current versions of J2ME, only one MIDlet ■ 
mobile information device 12. A MIDlet 
the mobile information device 12 



can be active at a time on the 
is run in a foreground mode (or is paused). If 
needs to process events requiring user interaction, the 
current MIDlet's execution is paused. 
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The original security model provided by the Java platform is known as the 
"sandbox model," which existed in order to provide a very restricted environment in 
which to run un-trusted code obtained from the open network 20. The essence of the 
sandbox model is that local code (e.g., applets stored on a device) was trusted to have full 
5 access to vital system resources (such as the file system or data) while downloaded 
remote code is not trusted and can access only the limited resources provided inside the 
sandbox. 

In the new Java 2 Platform Security Architecture, there is no longer a built-in 
concept that all local code is trusted. Instead, new local code (e.g., MIDlets downloaded 
10 from the network 20 and installed on the local file system) is subjected to the same 
security control as non-local code in the original security model. 

For security reasons, it is assumed that MIDlets within a MEDlet Suite packaged 
together are able interoperate. MIDlets within a MIDlet Suite are able to interoperate 
because they share the same name space. Since they share the same name space, the 
15 MIDlets in a MIDlet Suite can launch one another. In the current version of J2ME one 
MIDlet Suite currently cannot launch MIDlets in another MIDlet Suite or share data with 
MIDlets in another MIDlet Suite because they do not share the same name space. 

The MIDP specification also does not define how one MIDlet can launch another 
MIDlet or act as a handler for another MIDlet or non-MIDlet application. The MIDP 
20 specification indicates that launching a MIDlet Suite is solely the responsibility of the 
JAM 58. 
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EXTENDING MIDlets 

To allow MIDlets in one MIDlet Suite to exchange or share data with MIDlets in 
another MIDlet Suite or with non-MIDlet applications, a new object-oriented application 
program interface is provided. This new object-oriented application program interface 
5 includes multiple object-oriented object classes with multiple object-oriented methods. 

The object-oriented application program interface includes multiple object- 
oriented object classes to allow input and output data to be communicated between J2ME 
MIDlets in different MIDlet Suites and MIDlets and non-MIDlet applications. The 
object-oriented application program interface is stored on a computer readable medium. 
10 The object-oriented application program interface includes at least a first object-oriented 
object class and a second-object oriented class, each with one or more object-oriented 
methods. 

The first object-oriented class accepts input data in a MIDlet in a MIDlet Suite 
from an application management system on a mobile information device when the 
15 MIDlet is invoked on the mobile information device. The input data is generated by 
another MIDlet in another MIDlet Suite (or by another non-MIDlet application). 

The second object-oriented object class for sets output data from a MIDlet in a 
MIDlet Suite when the MIDlet is terminated on a mobile information device. The output 
data is available to an application management system on the mobile information device 
20 and can be used by other MIDlets in other MIDlet Suites, or by non-MIDlet applications. 

In one embodiment of the present invention, the object-oriented application 
program interface is a J2ME API called "com.sprintpcs.util." However, the present 
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invention is not limited to this exemplary J2ME API and other J2ME APIs with other 
monikers can also be used. 

FIG. 7 illustrates the exemplary "com.sprintpcs.utir API 88. This API 88 
includes a System object class 90 and a Muglet object class 92. However, the present 
5 invention is not limited to this embodiment and other embodiments with more or fewer 
object classes can also be used. In addition, the API 88 and the object-classes included 
therein can use any monikers and are not limited to the monikers described. 

One type of data that can be passed between MIDlets from different MIDlet 
Suites or other non-MIDlet applications, is a Uniform Resource Identifier ("URI"). 
10 However, the present invention is not limited to passing URI data between MIDlets and 
other types of data can also be used. 

As is known in the art a URI is a generic term for all types of identifiers that refer 
to objects on the Internet. In J2ME, URI( ) is a string that is designed to handle the 
parsing of URIs and provide access to the various components (scheme, host, port, 
15 userinfo, path, query string and fragment). 

At the highest level a URI reference (hereinafter "URI string") in string form has 
the syntax [scheme : ]scheme-specific-part[#fragment], where square brackets "[...]" 
delineate optional components and the characters colon (":") and pound ("#") delineate 
other components. An absolute URI specifies a scheme; a URI that is not absolute is said 
20 to be relative, URIs are also classified according to whether they are "opaque" or 
"hierarchical". 
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An o P a q ue URI is an absolute URI whose scheme . specific part ^ ^ ^ 
wUh a slash character («/»). 0 pa que URIs are not subject to ^ ^ ^ 
examples of opaque URIs are illustrated in Table 5. 



mailto:user@sprint.com Ih^T 
news:comD.lana jgm^j^p^ 



Table. 5 



A WeW UR! is eilher an abso , ute ^ whMe scWspecjfe ^ beg . ns 
w«h a sl ash character pr, „ r a relalive ^ that is> . ^ ^ ^ ^ ^ ^ 
scheme. A hierarchical URI is subject ,„ further parsing . Tab|e , a few 

examples of hierarchical URIs. 



http://sun.javaTcom^2me 
docs/guide/collections/j2me 
••/../../sprint/demo/j2me 
file:/, ./-calendar 



10 



Table 6. 



Parsing of a URI string wWl the mi( , ^ ^ . ^ ^ ^ ^ 

surtax described in IETF-RFC 2396, i„corpora t ed herein by reference. Every URI 

consists of a scheme, followed by a colon <"'•". f„n ^ i_ 

oyacolon( . X followed by a scheme-specific part For 

« ^hea (■/,•) and may be foHowed by an authority segment (comprised of user 
tnformatton, host, and port), path segment, que ry segment and fragment. 

Par, is treated as the >«, portion of the URI. Un,i k e the javameUIRX Cass, the I 2ME 
"KK ) s«ng does no, provide any buih-m network access mncbonahty nor does i, 
* ^^-y^-specif l c f „„c ti o„a ll ,y ( fore X am pl e, 1I d„es„o tknoW adefau,tp„r, 
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for a specific scheme). Rather, it only knows the grammar and basic set of operations that 
can be applied to a URI string. 

Another description of data that can be passed to and from MEDlets is a 
Multipurpose Internet Mail Extension ("MIME") media type definition for text, audio, 
5 video, images, applications, etc. MIME media descriptions used in URIs are described in 
IETF-RFCs 2045, 2046 and 2047, incorporated by reference. Other descriptions of 
Internet media types can also be used for the data that is passed to and from MIDlets, and 
the present invention is not limited to URIs or MIME descriptions. 

Returning to FIG. 7, the exemplary System object class 90 includes two object 

10 methods: (1) appendReferringURI( ); and (2) setExitURI( ). However, the present 

invention is not limited to these object methods and more fewer or other object methods 
can also be used in the exemplary System object class 90. For example, in one 
exemplary embodiment, the System object class 90 implements only the setExitURI( ) 
and not the appendReferringURI( ). In addition, the present invention is not limited to 

15 the monikers used, or object- functionality described for the System object class 90. 
Other monikers and more, fewer, or other object- functionality can also be used. 

The object-method appendReferringURI( ) sets a string that is passed to the JAM 
58 and appended to the URI identifying a MIDlet, when the MIDlet invokes another 
MIDlet or another application through the setExitURI( ) object method. The object 

20 method setExitURI( ) sets a URI what is passed to the JAM 58 and invoked according to 
the rules of URI scheme and Internet media type processing. 
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Details of the exemplary System object class 90 are illustrated in Table 7. 
However, the present invention is not limited to the implementation details described for 



exemplary System object class 90 and other implementation details can also be used. 



Public class System 
Extends java.lang. Object 

Methods inherited by System( ) from class 
java.lang. Object: 

(clone, equals, finalize, getClass, hashCode, notify, notifyAII, 
toString, wait, wait, wait) 

Public System( ) 


System Object Class 90 
Object Methods Summary 


public static void 

appendReferringURI(java lang String 
appendText) 


Sets a string which is passed to the 
JAM 58 and appended to the URI 
identifying the MIDIet when the 
MIDIet invokes another application 
through the setExitURI( ) method. A 
zero-length string or null will result in 
the base URI for the MIDIet being 
the referring URI when setExitURI( ) 
is called. 

Parameters: 

appendText - The text string to be 
appended to the referring URI 


public static void 

setExitURI(java.lang. String exitURI) 


Sets a URI that is passed to the JAM 
58 and invoked according to the 
rules of scheme and media type 
processing. Any path may be set; a 
zero-length string or null disables the 
exit-URI functionality. Defaults to 
null. 

Parameters: 

exitURI - URI invoked after 
application exits 



Table 7. 



5 Returning again to FIG. 7, the exemplary Muglet object class 92 includes four 
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object methods: (1) getMediaType( ); (2) getMuglet( ); (3) getReferringURI( ); and (4) 

getURI( ). However, the present invention is not limited to these object methods and 
more fewer or other object methods can also be used in the Muglet object class 92. In 
addition, the present invention is not limited to the monikers used or object- functionality 
5 described for the Muglet object class 92. Other monikers and more or other object- 
functionality can also be used. 

The object method getMediaType( ) returns a string including an Internet media 
type (e.g., a MIME type) of an object when a Muglet is invoked. When a Muglet is 
invoked to handle a URI scheme, this object-method returns null. The object method 

10 getMuglet( ) returns a Muglet instance associated with the invocation of a MEDlet. The 
object method getReferringURI( ) returns a string including the URI of a Web/WAP page 
or another Muglet that referenced an object resulting in the invocation of a Muglet to 
handle an Internet media type or identification of another MIDlet. The object-method 
getURI( ) returns a string including a temporary name that may be passed to another 

15 object-method (e.g., J2ME Connector.open( ) ) in order to access an object when the 
Muglet describes one (e.g., when getMediaType( ) returns a string). 

Details of the exemplary Muglet object class 92 are illustrated in Table 8. 
However, the present invention is not limited to the implementation details described for 
exemplary Muglet object class 92 and other implementation details can also be used. 
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Public class Muglet 
Extends java.lang. Object 

M thods inherited by Muglet( ) from class 
java.lang. Object: 

(clone, equals, finalize, getClass, hashCode, 
notify, notifyAII, toString, wait, wait, wait) 

Public Muglet( ) 


Muglet Obj ct Class 92 
Object Methods Summary 


public static Muglet 
getMuglet( ) 


Return the Muglet instance associated with 
the invocation of this MIDIet. If this MIDIet 
was invoked as a Muglet scheme and 
media-type handler, a single instance is 
created and the same instance is returned 
each time this method is invoked. If this 
MIDIet was not invoked as a Muglet, no 
instance is created and null is returned. 

Returns: 

Null if MIDIet not invoked as a Muglet, 
otherwise the single instance of Muglet. 


public java.lang. String 
GetContentType( ) 


Returns a string including the content type 
of an object when a Muglet is invoked; 
when a Muglet is invoked to handle a URI 
scheme, this method returns null. 

Returns: 

Null if Muglet is invoked to handle a URI 
scheme. 


public java.lang. String 
GetMediaType( ) 


Returns a string including the Internet 
media type of an object when a Muglet is 
invoked; when a Muglet is invoked to 
handle a URI scheme, this method returns 
null. 

Returns: 

Null if Muglet is invoked to handle a URI 
scheme. 
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public java.lang.String 
getURI( ) 



Public java.lang.String 
getReferringURI( ) 



nsm T\ 3 f 1 " 9 includin 9 a temporary 
name which may be passed to 
Connector.openO in order to access an 
object when the Muglet describes or »e 
(*m getMediaTypeO returns a sSg) 
When no object is present and the Set 

the , ^ in!? h 38 8 SCh6me hand '- 
This meS l "'' Ud,n 9 schem e- « returned, 
nis method does not return null. 



Returns: 



A string including a URI or pathname. 



Returns a string including the URI of a 
web vvap page that referenced an object 
resul bng in the invocation of a Sole So 
handle an Internet media type.Tf no 
refemng URI exists for any reason thk 
method returns null V tn,s 



Returns: 



A string including a URI or a null. 



Table 8. 



FIG. 8 is a flow diagram illustrating Method 94 for P u ■ 

g ivietnod 94 for exchanging output data 

^. AtStep9(i , a , 2ME 

; na ^^ A '^'Mu, uttoaiSMtftomfteMmietbeforetheMiDktis 
, ei „ fcmationdeviceandcanbeusedbyofterMmasint 
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MEDlet Suites or non-MIDlet applications on the mobile information device. 

Method 94 may further comprise appending an identifier for the MEDlet to the 
generating referring URL The identifier is used by another MIDlet or another non- 
MEDlet application invoked by the MIDlet to identify the MIDlet. For example, it may 
5 be used to identify the MIDlet that set the output data. 

Method 94 is illustrated with an exemplary embodiment. However, the present 
invention is not limited to this embodiment and other embodiments can also be used to 
practice the invention. In such an exemplary embodiment at Step 96, a J2ME MIDlet is 
executed on the mobile information device 12. The MIDlet has the setExitURI( ) object- 
10 oriented method from the System( ) 90 object class available for setting output data 
including URI strings. 

At Step 98, output data including a URI string is set from the MIDlet before the 
MIDlet is terminated on the mobile information device 12 using the setExitURI( ) object- 
oriented method. The output data is available to the JAM 58 on the mobile information 

15 device 12. The JAM 58 makes the output data available to other MIDlets in the same or 
another MIDlet suite or other non-MIDlet applications. 

The "Exit URI" functionality of the exemplary System object class 90 allows a 
MIDlet to tell the JAM 58 to access a specific URI upon exit from the MIDlet. The 
MIDlet may set the exit URI at any time during its execution, and may change the exit 
20 URI as many times as necessary during its execution. If the MIDlet exits on its own (i.e., 
by calling notifyDestroyed instead of being killed by the JAM 58 calling destroyApp( ) ), 
the JAM 58 will access the URI provided by the MIDlet. 

36 

McDonnell Boehncn 

Hulbert & Berghoff 
300 South Wacker Drive 
Chicago I L, 60606 
(312) 913-0001 



Method 94 may further comprise appending a string identifier for the MIDlet to 
the generating referring URL The string identifier is used by another MIDlet or another 
non-MIDlet application invoked by the MIDlet to identify the invoking MIDlet. The 
"referring URI string" functionality can also be used by a MIDlet in conjunction with the 
5 "Exit URI" functionality. 

USING INPUT DATA SET BY MIDlets 

FIG. 9 is a flow diagram illustrating a Method 100 for using input data on 
portable applications on a mobile information device. At Step 102, a J2ME MIDlet is 
10 invoked on from an application management system on the mobile information device. 
The MIDlet has plural object-oriented methods in an object-oriented object class 
available for using input data created by other MIDlets. At Step 104, input data created 
by another MIDlet is accepted from the application management system on the MIDlet 
using one or more of the plural object-oriented methods from the object oriented class. 

15 Method 100 is illustrated with an exemplary embodiment. However, the present 

invention is not limited to this embodiment and other embodiments can also be used to 
practice the invention. In such an exemplary embodiment at Step 100, a J2ME MIDlet is 
invoked on the mobile information device 12 from the JAM 58. The MIDlet has the four 
object-oriented methods from the Muglet 92 object class available for using input data 

20 including a URI scheme or an Internet media type (e.g., MIME type) created by other 
MIDlets. At Step 104, input data including a URI scheme or an Internet media type 
created by another MIDlet or a non-MIDlet application is accepted from the JAM 58 on 
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the MIDlet using one or more of the object-oriented methods from Muglet 92 object 
class. 

FIG. 10 is a flow diagram illustrating a Method 106 for invoking a MIDlet as a 
MIDlet handler. At Step 108, a J2ME MIDlet is invoked from an application 
5 management system on the mobile information device as a MIDlet handler. The MIDlet 
handler includes plural object-oriented methods in an object-oriented object class 
available for using input data created by other MIDlets. Step 1 10, an object-oriented 
method in the object-oriented object class is called from the MIDlet handler to determine 
what type of input data will be processed by the MIDlet handler. The object-oriented 
10 method returns a return value. At Step 112, the input data is processed based on the 
return value by calling one or more other object-oriented methods in the object-oriented 
object class. At Step 1 14, another MIDlet is invoked from the MIDlet handler using the 
processed input data. 

Method 106 is illustrated with an exemplary embodiment. However, the present 

15 invention is not limited to this embodiment and other embodiments can also be used to 

practice the invention. In such an exemplary embodiment at Step 108, a J2ME MIDlet is 

invoked from the JAM 58 on the mobile information device 12 as a Muglet acting as a 

MIDlet handler. The Muglet includes the plural object-oriented methods from the 

Muglet object class 92 that available for using input data such as URI schemes and 

20 Internet media types created by other MIDlets or other non-MIDlet applications. 

A MIDlet intended to process one or more type of URI scheme or Internet media 

type can be invoked as a MIDlet handler via the Muglet object class 92. A Muglet is 

constructed as a standard MIDlet, and may make use of the full range of features 
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available to MIDlets. Additionally, such a Muglet enumerates which URI schemes and 
Internet media types are handled by including certain properties in a corrsponding MIDlet 
Suite. When installed into a mobile information device 12, MIDlet Suite properties are 
used to configure the Muglet(s) to handle the specified URI chemes and Internet media 
5 types for other MIDlets and non-MIDlet applications on the mobile information device 
12. Such a model may be similar to how common desktop web-browsers use 'plug-in' 
modules and external applications. 

However, unlike plug-ins in the desktop web-browser environment, Muglet URI 
scheme and media type handlers do not run as extensions to a browser and do not have 
10 access to the browser context. Instead, Muglet URI scheme and media type handlers are 
independently-running applications. 

Returning to FIG. 10, at Step 1 10, once invoked, a Muglet calls the 
GetMediaType( ) object method to determine what, if any, URI scheme or media type 
triggered execution of the Muglet. 

15 Returned from the GetMediaType( ) object method is string that specifies a type 

and value of a URI scheme or Internet media type. In addition, a name can be provided 
in the case of an Internet media type that provides access to an actual object (e.g., via the 
J2ME Connector.openInputStream( ) object method). 

At Step 112, the URI scheme or Internet Media Type is processed based on the 
20 return value of the GetMediaType( ) object method by calling one or more other object- 
oriented methods including getURI( ), getReferringURI( ) or getMuglet( ) in Muglet 
object class 92. 
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If a Muglet is invoked to handle a scheme or media type which is not recognized, 
the Muglet may exit immediately. It is possible to build a Muglet that runs as a URI 
scheme and Internet media type handler when invoked as such, and otherwise runs as a 
conventional MIDlet. 

5 At Step 1 14, another MIDlet is invoked from the MIDlet handler using the 

processed input data. As is the case with standard J2ME MIDP implementation, only one 
MIDlet or non-MIDlet applications runs at any one time in the mobile information device 
12, and there is no facility to have more than one Muglet URI scheme or Internet media 
type handler running at the same time. 

10 In one embodiment, when a Muglet is invoked to handle a URI scheme or Internet 

media type, a MIDlet or non-MIDlet application being executed is suspended for the 
duration of the Muglet execution. Once the Muglet execution is complete, the invoking 
MIDlet or non-MIDlet application is resumed. It is possible, however, that the invoked 
application may itself use the Muglet functionality to exit to another application instead 

15 of returning to the original invoking application. This can cause the original invoking 
application to remain in a perpetually suspended state, thereby causing hanging system 
resources. Thus, in another embodiment, a MIDlet or non-MIDlet application must exit 
in order to call a Muglet. 

Once invoked, a Muglet URI scheme or Internet media type handler has complete 
20 control over the interpretation of the URI scheme, Internet media type or object. Any 
errors in these items are handled as the Muglet desires. 

A Muglet may also receive a referring URI string via the getReferringURI( ) 
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object-oriented method from the Muglet object class 92. This URI string indicates the 
application or URL location from which the Muglet was invoked, and may be used by the 
Muglet as an exit URI when it terminates, so that control can be returned to a previous 
context. 

5 For example, if a Muglet is invoked from a Web page as an Internet media type 

handler, it could set the exit URI string to the value of the incoming referring URI string, 
such that the mobile information device 12 would be returned to the same Web page 
being viewed when the Muglet exits. If the Muglet chooses to exit to another URI string 
or to no URI string, it may discard the referring URI string. 

10 

JAM SUPPORT FOR EXCHANGING INPUT AND OUTPUT DATA 

In one embodiment of the present invention, the JAM 58 is built around the 
concept of a registry. The registry maintains information about what MIDlets or non- 
MIDlet applications are invoked to handle specific media types and URI schemes. The 
15 registry may include both MIDlet and non-MIDlet applications. 

When a J2ME MIDlet is installed by the JAM 58, the JAD file 72 may specify 
content types that are handled by a MIDlet through one or more instances of a Content- 
<n>-Handler attribute as described below. A user of a mobile information device 12 is 
prompted to confirm the registration of the MIDlet as a scheme or media type handler. If 
20 there is already a handler registered for that scheme or media type, the user may be 
prompted to confirm the replacement or keep the existing handler registration. 

The handler type and URI scheme or Internet media type name for an "n-th 
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MIDlet" in a MIDlet Suite is specified as comma-separated strings. A handler type 
currently includes "uri-scheme" or "media-type". However, the present invention is not 
limited to these handler types and more or other handler types can also be used. Table 9 
indicates exemplary handler type examples. 



5 



Handler type Example 


Description 


Content-1 -Handler: uri-scheme, mailto 


A MIDlet that provides an enhanced email 
handler. 


Content-2-Handler: media-type, image/gif 


A MIDlet that provides a viewer for Graphic 
Interchange Format ("GIF") files. 



Table 9. 

Any properties in the MIDlet Suite specifying URI scheme or Internet media type 
handlers should also be present a corresponding J AD file 72. If the JAM 58 determines 

10 that any of the Internet media types and/or URI schemes that the JAD file 72 is 

attempting to register cannot be registered (e.g., because they are protected media types 
or URI scheme), the JAM 58 will not download the JAR file 70, and will post a response 
with a "906 Invalid Descriptor" error code. More information on how MIDlet suites can 
be deployed over-the-air ("OTA") may be found in the "Over The Air User Initiated 

15 Provisioning Recommended Practice for the Mobile Information Device Profile," version 
1 .0, dated May 7, 2001, which is incorporated herein by reference. 

When the JAM 58 receives a URI string to process, it determines the appropriate 
application to handle the corresponding URI scheme based on the registry entries. There 
are several sources of URI's that the JAM 58 handles, including URI strings from: (1) an 
20 exit URI from a MIDlet set by setExitURI( ); (2) a mirco-browser; (3) a push message 
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(e.g., Service Indication or Service Loading messages); or (4) native non-MIDlet 
applications. 

Table 10 shows an example list of predefined URLs and their corresponding 
mappings. A Muglet implementation may includes a greater or fewer number of 
5 predefined URL mappings, and it may include URL mappings other than those listed in 
Table 10. Other URL schemes can be handled by an installed a MIDlet that implements 
the Muglet object class 92. 



Scheme 


Scheme Handling 


http: https: 


Launch mirco-browser 62 and get an indicated 
URL. 


midlet: 


Launch a specified MIDlet. 


ams: 


Launch specified content. 


tel: 


Place a phone call to the indicated phone 
number. (See IETF-RFC 2806, incorporated 
herein by reference). 


im: 


Invoke a native instant messaging client 
application. 



Table 10. 

When the JAM 58 invokes a MIDlet as a Muglet (e.g., as a URI scheme or 
10 Internet media type handler), it passes in the referring URI string to the Muglet, if 

available. If the Muglet was invoked from a link or content on a browser page, the URL 
of the page is used as the referring URI. If the Muglet was invoked due to an exit URI 
from another MIDlet, the JAM 58 appends a string provided by the exiting MIDlet to the 
Muglet using the appendReferringURI( ) object oriented method, and the Muglet uses the 
15 resulting URI as the referring URI. If a Muglet is invoked due to the user selecting it to 
handle stored content that the user selects to view, or due to a URI string in a notification, 
the referring URI string will be null. 

A URI scheme allows another MIDlet to be specifically identified by other 
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MIDlet and non-MIDlet applications. The scheme specific portion of the MIDlet URI 
includes fully qualified class name of a class that extends MIDlet (e.g., Muglet), and may 
refer to a specific MIDlet within a MIDlet Suite. The URI string may also include a 
query component that with parameters for a MIDlet by including a question mark ("?") 
5 and a series of URL-encoded parameters after the fully qualified class name. 

The entire URI scheme will be passed to the Muglet by the JAM 58 via the 
Muglet. getURI() object-oriented method. For example, the URI string: 

<a href- 'midlet:com.sprintpcs.apps.calendar?date- '2001 1003"> 

would launch a calendar MIDlet from "com.sprintpcs.apps" with the date set to October 
10 3, 2001, from a Muglet. 

The JAM 58 also supports the ability to "launch" stored non-java content by 
handling URI string with a scheme of ("ams:") and a scheme-specific part that is a 
content-ID of the target content. For example, the URI string 

<a href="ams:sprintpcs.com.example_content"> in a browser page would cause an ams: 
15 URI to be passed to the AMS, which would launch an appropriate handler for the stored 
content with a content-ID associated with "example_content." 

If the JAM 58 encounters any URI that does not have a pre-defined handling 
requirement as described above in Table 10, it will attempt to locate a MIDlet that is 
registered to handle the scheme type using the registry. If such a MIDlet is located, the 
20 JAM 58 will launch the MIDlet and pass the URI string to the MIDlet through the 
Muglet. getURI( ) object-oriented method. 

When the JAM 58 receives a content file to process, it will determine the 
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appropriate application to handle that content-type based on the registry entries. There 
are at least three sources of content that the JAM 58 may need to handle, including: (1) 
"ams: content" stored content folders; (2) files downloaded by micro-browser 62; or (3) 
content from other native applications. 

When a content type handled by a MIDlet is needs to be processed, the 
application that downloaded or generated the content passes both a content and a MIME 
or other Internet content-type to the JAM 58. The JAM 58 determines an appropriate 
Muglet (i.e., MIDlet handler) based on the registry, and launches the appropriate MIDlet. 

The JAM 58 will pass the content-type to the Muglet through the 
Muglet. getContentType( ) object-oriented method, and will pass a locally significant URI 
string to the Muglet via the Muglet.getURI( ) method. When the Muglet passes this URI 
string to the J2ME Connector.open( ) object-oriented method, the JAM 58 will return a 
stream connection to a buffer that is holding the content. 

The ability to invoke content, applications, services, downloads, etc. on the device 
from a push message is also supported. When a messaging client receives a WAP 
Service Indication ("SI") or Service Loading ("SL") message, the message may include a 
URI field. The handling of these messages is the responsibility of the messaging client, 
which will invoke the JAM 58 to handle the embedded URI scheme. Service Loading 
messages will cause the URI to be invoked without user intervention, and are generated 
from trusted carrier systems. Service Indication messages present text to the user, who 
can then elect to invoke the URI. In either case, the URI will be passed to the JAM 58 
for handling. 
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Once MIDlet A 152 terminates, the application management system 150 may 
determine which application is registered to handle the output data generated by MIDlet 
A 152. For example, the application management system 150 may check to determine an 
application registered to handle a scheme of the output data generated by MIDlet A 152. 
5 The application management system 150 may then launch the application that is 
registered to handle that scheme. 

As shown in FIG. 1 1, the application management system 150 launches MIDlet C 
158 to handle the output data set by MIDlet A 152. At dataflow 160, MIDlet C 156 uses 
the getURI() object-oriented method to obtain the output data set by MIDlet A 152. In 
10 response, the application management system 150 returns to MIDlet C 158 the "A" 
output data, shown generally by dataflow 162. 

Depending on the type of output data set by MIDlet A 152, MIDlet C 158 may 
optionally use one or more of getMediaType( ), getContentType( ), getMuglet( ), 
getReferring( ) or other object-object oriented methods to obtain the output data set by 
15 MIDlet A 152. These may be used in conjunction with or in place of the getURI( ) 
object-oriented method shown at dataflow 160. 

MIDlet C 158 may additionally use the getReferringURI( ) object-oriented 
method to obtain additional output data set by MIDlet A 152. The getReferringURI( ) 
object-oriented method can be used to obtain the output data set by MIDlet A 152 via the 
20 appendReferringURI( ) object-oriented method. At dataflow 164, MIDlet C 158 uses the 
getReferringURI( ) object-oriented method to obtain additional output data set by MIDlet 
A 152. In response to the getReferringURI( ) object-oriented method, and as shown at 
dataflow 166, the application management system 150 returns parameters "A" and "B" to 
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MIDlet C 158. Parameter "A" identifies MIDlet A 152, which invoked MIDlet C 158. 
Parameter "B" is the additional data that MIDlet A 152 passed to the application 
management system 150 via the appendReferringURI( ) object-oriented method. 
Many different variations may be made to the operation of the application 
5 management system 150. While FIG. 1 1 depicts the application management system 150 
passing data between two different MIDlets, the application management system 150 
may alternatively pass data between a MIDlet and a non-MIDlet application. For 
example, MIDlet A 152 might be replaced by a non-MIDlet application, such that the 
non-MIDlet application generates output data that the application management system 

10 1 50 then passes to MIDlet C 1 58. In another example, MIDlet C 1 58 might be replaced 
by a non-MIDlet application, such that the application management system 150 receives 
output data from MIDlet A 152 that the application management system 150 passes to the 
non-MIDlet application. 

FIG. 12 is a flowchart of an exemplary process for an application management 

15 system to receive input data from an application and to pass the input data to a first Java 
MIDlet in a first Java MIDlet suite. At Step 200, the application management system 
accepts input data from an application on a mobile information device. In one 
embodiment, the application may be a non-MIDlet application. In another embodiment, 
the application may be a Java MIDlet. 

20 Then, at Step 202, the application management system passes the input data to a 

first Java MIDlet in a first MIDlet suite on the mobile information device. Where the 
application that created the input data is a Java MIDlet, it may be in a different MIDlet 
suite than the first Java MIDlet. Thus, the application management system may use this 
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Pass .he i„p„, data t0 . Mroiet in anoter MIDle( su . e Aitema(jveiy _ ^ 
manage™™, system may use ^ method t0 ^ ^ ^ ^ a ^ ^ 
application and then pass the input data to a MIDI* application. 

FIG. 13 is a flowchart of an exemplary process for an application management 
system ,„ receive inpu, data flom a first lava MDDlet in a firs, MID,* suite and t0 pass 
•he input data to an appfication. At Step 220, the applicauon management sys,em accepts 

device. Thus, the inpu, da,a to the applieation management system can he output from 
0 .hefi re u„,e, The„,a,S,ep 222 , th e a p plicatlonmanagementsy$tempassesthe 
■npu. da,a ,o an apphcafion on the mobile information dev.ee. The app,ica,io„ may he 

apphcalion may be a non-MlDlet applicalion. 

FIG. ,4 is a flowchart of an exemplary process for an apphcation management 
sys,em ,o pass „„«pu, da,a between applicafions on a mobile infonnation device. At S,ep 
240, ,he application management system receives outpu, data fiom a firs, Mflflet in a 
«-MID,e, S ui,eo„,he m oh I ,e,„f„ m a,io„device, wherein ,he output data ts received 
before the firs, MIDle, t e m i„a,e, A, Step 242 , me apphcafion management svs,e m 
launch* an apphcafion in the mobile infonnafion device. The apphcafion may be for 
example, a „o„-M,D,e, application or MID* in a different MIDlet sui.e than the firs, 
MIDle,. Then, a, S,ep 2 44, the application management system passes the outpu, da,a ,o 
the application. 
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FIG. 15 is a flowchart of an exemplary process for an application management 
system to exchange data between applications on a mobile information device. At Step 
260, the application management system receives output data form an application on the 
mobile information device. The application may be, for example, a MIDlet or non- 
5 MIDlet application. The application management system may then launch a first MIDlet 
in a first MIDlet suite on the mobile information device. If the application is a MIDlet 
application, it may be in a different MIDlet suite than the first MIDlet. The application 
management system may then pass the output data to the first MIDlet, as shown at Step 
264. 

10 FIG. 16 is a flowchart of an exemplary process for an application management 

system to pass data between MIDlets in different MIDlet suites on a mobile information 
device. At Step 280, the application management system receives input data form a first 
MIDlet in a first MIDlet suite on the mobile information device. Then, at Step 282, the 
application management system determines a type of the input data. The application 

15 management system then determines that a second MIDlet in a second MIDlet suite is 
registered to handle the type of the input data, as shown at Step 284. The application 
management system then launches the second MIDlet on the mobile information device, 
as shown at Step 286. Finally, at Step 288, the application management system passes 
the input data to the second MIDlet. 

20 

PUSH LAUNCHING APPLICATIONS WITH CONTEXT 

The application management system 150 may be used to perform a variety of 

different functions on the mobile information device, such as launching MIDlets. Once 
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the application management system 150 launches a MIDlet, the application management 
system 150 can use the previously described object-oriented methods to pass data to the 
MIDlet. An application, such as one executing on another device, may advantageously 
use the ability of the application management system 150 to pass data to an executing 
5 MIDlet in order to push launch an application with context on the mobile information 
device. 

FIG. 17 is a block diagram illustrating an exemplary operation of the application 
management system push launching an application with context on the mobile 
information device. A universal message handler 300 executes on the mobile 
10 information device. The universal message handler 300 can continually execute on the 
mobile information device and listen for push messages sent to the mobile information 
device. The universal message handler 300 may additionally listen for other types of 
messages as well. 

As depicted in FIG. 17, the universal message handler 300 receives a push 
15 message via dataflow 302. The push message may be any type of push message, such as 
a WAP push message. The push message may include a URI, MIME media type or other 
identifier used in specifying an application to launch on the mobile information device. 
Once the universal message handler 300 receives the push message, the universal 
message handler 300 processes the push message in order to launch an application on the 
20 mobile information device. 

The response of the universal message handler 300 to the push message may vary 
depending on a type of the push message. For example, a WAP Service Loading push 
message may be used to automatically launch an application on the mobile information 
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device withou, quiring approva, by .he user of ,he mobile inf 0mation device prjor „ 
.aunching the app.ica.ion. Thus, ifthe u„ive„a, message haodier 300 receives a WAP 

launch .he app,ica t i„„ „ by the WAp ^ ^ ^ ^ ^ ^ 
' approva, from .he user of .he mohiie i„ fomatio „ devic , Fof ^ ^ 

app.ica.ion nranagemen. sys.em ,50, which may in ,um ,a„neh an ap p, ication based „ 
the contents of the WAP Service Loading push message. 

A WAP Service indication push message, however, requires approva , 6om [he 

>he WAP Service Loading p ush messag , Thus> ^ ^ ^ ^ ^ 

firs. req ues« appro™, from the user of the mohi.e Nation device. As shown in 
- mohde information device via a popup 3M ^ some 

*e universa, message ha„d,er 300 wou,d no, proceed ,„ push iauneh the app.ieatiort . 

300 does receive „ from the user, the u„iver Sa , message handier 300 m ay men 
» Pass -he WAP Servtce In dic a ,io„ push message to ,he apphcation management system 
■50, which may in ,„ m , aunch the ^ fcy ^ ^ ^ ^ 

W,ca„o„ push message dlrect|y (0 ^ ^ ^ ^ 
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tion 



may 



— message hand.er 300 may ahemativeiy provide applicatl0 „ 

system ,50 with some „ lher indication of the WAp ^ ^ ^ 

°«e t he application management system 150 receives a push message from the 
untversa, message ha„ d ,e r 300, the appheation management system , 50 may then 
> fe.enntne an appheation regrstered to handle the push message. For examp,., tta . push 
-sage specifies a UR, scheme associated with mstant messaging, then the apphca* 
ntanagemen, system ,50 may define whieh appheation on the mobfle information 
devtee is register, for i„ stant messagin , ne ^ ^ 

•hen ,a„„eh tha, app,i catl0 „ if it is not a|ready ^ ^ ^ ^ 
.» device. As depicted in FIG. 

appheation, a„ d therefore in response to receiving the push message the appheation 
management system ,50 launches an instant messaging MIDIet 306. 

The instant messaging MID,e« 306 may then interact with the appheation 

« application management system , 50 am, the i„ stant messaglng ^ 3Q6 ^ fc 
dataflow 308 using any of the previous,, described o bj ec ( -orie„,e d methods. P„ r 
exampie, the appheation management system ,50 may pass data to the instant messagmg 
MDOle. 306, or the instan, messaging MIDIet 306 may pass data to the appheation 
management system 150. 

Using the previousiy described object-oriented methods to pass data between the 
appheation management system 1 50 and the instan, messaging M,D,e, 306 can aflow the 
appheation management system ,50 to ,au„ch the instan, messaging MIDIet 306 with a 
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application management system 150 may pass ,„ the instant messaging MIDlet 306 the 
URI specified in the push message, and the URI may include parameters that the instan, 
messaging MID,* 306 uses in establishing an instant messagmg session ^ , ^ 
context. 

For example, the URI may specify a particular user wifh which the instant 
messaging MIDie, 306 should proceed ,„ establish the instant messaging session. Thus, 
the apphcation management system 150 may launch the instant messaging MIDlet 306 in 
response to the push message, and the application management system ,50 may then pass 
the URI inoluded in the push message to the instant messaging MJDlet 306. The instant 
.» messaging MIDlet 306 can then use the URI ,„ responsive , y eslab „, h „ ^ 

messaging session with the user specified in Ore URI without firs, requiring any input by 
the user of the mobile information device. 

Specifying the user with which to establish the instan, messaging session is 
merely one example of a parameter specified m .he URI mat may be used ,„ push launch 
•he instan, messaging MIDlet 306 wifh a particular context. The push message may also 
include parameters other man those specified in the URI, and fhese ofher parameters may 
also be used to push launch the instan, messaging MIDlet 306 with a particular con.ex, 
The application managemen, sys,em 150 may also pass these o,her parameters ,„ the 
instan, messaging MIDle, 306 using me previously described object-oriented methods, 
and these other parameters may be in addition to or in p.aee of parameters specified in a 
URI. 

If the application management system 150 did not have the ability to pass the URI 

or other parameters to the instant messaging MIDlet 306 annii™, • 

gmg iviujiet 3()o, application management system 
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150 could launch the instant messaging MIDlet 306 in response to the pnsh message bu, 
would be unable t o establish a particular context for the instant messaging MIDlet 306. 
Any such parameters wonld have to come from the user of the mobile information 
device. However, using the previously described object-oriented methods to pass data 
5 between the application management system ,50 and the instan, messaging »«, 306 
can advantageously allow another application to push launch the instan, mes sagi ng 
MDta 306 on the mobile information devtce with a particnlar context. 

Instant messaging is merely one example of nsing the application management 
^em. ,50 to pnsh launch an application wtth context on the ntobile htfomtation devtce. 
.0 The application management system ,50 may pnsh launch other types of apphcations 
with context as well For examp,e, the nniversal message handler 300 may receive a 
push nressage that includes a UR, for a particular webpage. The apphcation ntanagemen, 
system ,50 may then define a MIDlet, such as a browser MID.et, which is regtstered 
,0 hand,c tha, tha, type of URI. The application management system ,50 may then 
lannch the browser MID,e, and pass i, the URI. Once the browser MIDlet receives the 
URI .he browser MIDle, may antomatically browse ,„ the webpage specified by the 
URI. 

In addition ,„ spectfying . webpage t0 which ,„ e ^ ^ ^ ^ 
'he UR, may additionally specify other pammetets used in establishing a context for the 
browser MIDlet. For example, the URI may inCude other data to be nsed in competing 
one or more fields in the webpage that are used ,„ fiarther configure the webpage. For 
example, the UR, may specify a webpage that provides stock q ao,es, and fine URI ma y 
mclude additional parameters ma, specify one or more stock, The browser » 9 may 
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then use the URI ,o browse to the stock quote webpage and ,o have the stock quote 
webpage display quotes for the stocks specified in the URI. 

Rather that simply touching the browser MIDlet in response to the push 
message, the application management system , 50 can use the previously described 
5 object-oriented methods ,„ pass the browser MIDlet a URI or other parameters ,ha, 

estabhshapartcular context for the browser MIDlet. Thus, another application can 
advantageouslypush launch the browser MIDlet and direct the browser MIDlet to browse 
to a particular URI, such as a webpage. The other application may further specify 
addttional information tha, can be used in configuring the „ ebpage , such „ lnfonna , ion 
10 that can be used to complete one or more fields in the webpage. 

I- should be understood, however, that many vanatious may be made the system 
described in FIG. 1 7. For example, the universal message handler 300 may be integrated 
into the application management system 150. The application management system 150 
may then monitor for push messages sen, to the mobile information device, h, another 
15 example, a component other than the universal message handler 300 may monitor for 
push messages sen, to the mobt.c information device. Other variations may be made as 
well. 

FIG. 18 is a flowchart of an exemplary process for an application management 
system push launchtng an apphcation with context on a mobile information device. At 
20 Step 320, the application management system receives on the mobile information device 
a push message that includes a URL The application management system then launches 
a lava MIDlet on the mobile inflation device ,„ handle the URI, as shown a. Step 322. 
At Step 324, the appltcation management system passes the URI ,o the Java MIDlet. 
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T W s m a ybedone , forexmp]e , usinganyoftheprevious|ydescribedobjMon ^ 
methods. 

FIG. .9 is a flowchart of an exemphry fe _ 

on a mob „e i„fonn at io„ device tadling . push message A( ^ ^ ^ 
* aPP.ica.ion ma „a g e m e„, system recelves on fte ^ ^ ^ ^ 

Step 342. For e Xamp , e , the applicatio „ ^ ^ ^ ^ ^ 

- appncaflon manag , meM systcm launches ^ ^ ^ ^ ^ ^ 

-,ce. Th e„, atStep34Mheapp|lcation _ gementsystempassestteTOitofc 

^^^^^^^^^^ 
onented methods. 



15 ^^^mmTOMcm 



THE U7VTVirp SA j MESSAGE 

FIG. 20 is a block diagram illustrating an exemplary 
executing on a mobile information device to 
20 universal message handler 300 

The universal message handler may determine 



operation for a Java MlDlet 
access the universal message handler. The 
may receive a push message, as shown at dataflow 302. 

that the push message should be handled 

by an instant messaging MIDlet. The universal 
URI to the application management : 



message handler 300 may then pass a 
system, as shown at dataflow 360. The universal 
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The universal message handler 300 may then pass the key to the application management 
system 150, as shown at dataflow 362. 

The application management system 1 50 may receive the URI and the key from 
the universal message handler 300. The application management system 150 may then 

5 determine an application registered to handle a type of the URL For example, as depicted 
in Figure 20, when the URI includes an instant messaging scheme, the application 
management system 150 may launch the instant messaging MIDlet 306. The application 
management system 150 may then pass the URI to the instant messaging MIDlet, as 
shown at dataflow 364. The application management system 150 may further pass the 

10 instant messaging MIDlet 306 the key, as shown at dataflow 366. The application 

management system 150 may pass the URI and key to the instant messaging MIDlet 306, 
for example, using the previously described object-oriented methods for passing data 
between MIDlets in different MIDlet suites and between a MIDlet and a non-MIDlet 
application. 

15 The instant messaging MIDlet 306 receives the URI and key from the application 

management system 150. The instant messaging MIDlet 306 may then provide the key to 
the universal message handler 300, as shown at dataflow 368. This may be also done, for 
example, using the previously described object-oriented methods. When the universal 
message handler 300 receives the key from the instant messaging MIDlet 306, the 

20 universal message handler 300 may then allow the instant messaging MIDlet 306 to 
access the universal message handler 300. After being granted access, the instant 
messaging MIDlet 306 and the universal message handler 300 may exchange data, as 
shown at dataflow 370. 
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Thus, using the functionality of the previously described object-oriented methods, 
the universal message handler 300 can pass keys to different MIDlets in order to allow 
the MIDlets to subsequently access the universal message handler 300. And, only 
MIDlets having a key from the universal message handler 300 would be able to access 
5 the universal message handler 300. It should be understood, however, that the instant 
messaging MIDlet 306 is merely exemplary in nature, and that the universal message 
handler 300 may selectively grant any other type of MIDlet access to the universal 
message handler 300. 

Not every application executing on the mobile information device necessarily 
10 needs to access the universal message handler 300. Some applications, such as instant 
messaging applications, may need access to the universal message handler 300 during 
their normal operation. Thus, the universal message handler 300 may selectively 
determine whether or not to grant a particular application access to the universal message 
handler 300. The universal message handler 300 may consider a variety of factors in 
15 making this determination, such as the type of the application. For applications that need 
access to the universal message handler 300 during their normal operation, the universal 
message handler 300 may generate a key that the application can use to access the 
universal message handler 300. For applications that would not normally need to access 
the universal message handler 300, the universal message handler 300 might not generate 
20 a key to be sent to those applications. 

FIG. 21 is a flowchart of an exemplary process for the application management 
system to allow an instant messaging application executing on the mobile information 
device to access the universal message handler. At Step 380, the application 
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management system receives from the universal message handler a URI that references 
the Java MIDlet. Then, at Step 382, the application management system receives from 
the universal message handler a key associated with the URI. The universal message 
handler may generate the key in order to allow an application holding the key to access 
5 the universal message handler. Although the key may be received separately from the 
URI, the key might alternatively be embedded in the URI. 

At Step 384, the application management system determines that a Java MIDlet is 
registered to handle the URI. The application management system then launches the Java 
r MIDlet on the mobile information device, as shown at Step 386. At Step 388, the 

10 application management system passes the URI to the Java MIDlet. This may be done, 
for example, using the previously described object-oriented methods for passing data 
between MIDlets in different MIDlets suites or between a MIDlet and a non-MIDlet 
application. At Step 390, the application management system passes the key to the Java 
MIDlet, and this may also be done using the previously described object-oriented 

15 methods. 

The Java MIDlet can then use the key to gain access to the universal message 
handler. For example, the Java MIDlet may provide the key to the universal message 
handler. After receiving the key, the universal message handler may then allow the Java 
MIDlet to access the universal message handler. Thus, instead of allowing all 
20 applications to access the universal message handler, the universal message handler 
would only grant access to applications that provide a valid key. 

FIG. 22 is a flowchart of an exemplary process for a Java MIDlet executing on a 
mobile information device to access the universal message handler. At Step 400, the Java 
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MIDlet receives from the application management system a URI that references the Java 
MIDlet. This may be done, for example, using the previously described object-oriented 
methods for exchanging data between MIDlets in different MIDlet suites or between a 
MIDlet and a non-MIDlet application. Then, at Step 402, the Java MIDlet receives from 
5 the application management system a key associated with the URI, and this may also be 
done using the previously described object-oriented methods. At Step 404, the Java 
MIDlet passes the key to the universal message handler in order to gain access to the 
universal message handler. Once the Java MIDlet has been granted access to the 
universal message handler, the universal message handler and the Java MIDlet may 

10 exchange data using the previously described object-oriented methods. 

FIG. 23 is a flowchart of an exemplary process for the universal message handler 
to grant access to a Java MIDlet executing on a mobile information device. At Step 420, 
the universal message handler receives a message on the mobile information device. For 
example, the universal message handler may receive a push message. At Step 422, the 

15 universal message handler generates based on the message a URI that references the Java 
MIDlet. At Step 424, the universal message handler provides the URI to an application 
management system. At Step 426, the universal message handler provides a key 
associated with the URI to the application management system. 

After receiving the URI, the application management system may launch a Java 

20 MIDlet that is registered to handle the URI. The application management system may 
then pass the key to the Java MIDlet. The Java MIDlet may gain access to the universal 
message handler by providing the key to the universal message handler. This may be 
done, for example, using the previously described object-oriented methods for 
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non-MID.e, ap pli oa ti o„. At S,ep 428, th e univca, message handier receives me key 
5 430. 

>• shou,d be unders,^ te fte programs , ^ ^ _ 

deacnbed here, are no, re,a,ed or fcw t0 my partlcu|ar type rf ^ _ ^ 
apparams (hardware or soaware), nn.ess i»dica,ed o,he™ IS e. Va™ ,ypes „ f gen era, 

,0 accordance w„h ,he .cachings described herein. Whiie various eiemems o f ,he preferred 
embod.me„,s have been described as being lmplemented in ^ h ^ 

embodiment in hardware or flm ,ware i m p ta e„,a,i„ ns may allemative , y be ^ ^ 
vice-versa. 

.» view of.be wide varie.y of embodiment .„ which ,he pri„ci pl e s of the preseM 
« — can be apphed, i, s h„n,d be a„ders,ood ta me illustr a,eo aMmm „ 

The ciaims sho„d no, be read as limM l0 me ^ ^ o , ^ ^ 

invoke 35 U.S.C. §I12 , paraph 6, and any c,a, m win™, ,he word w is no, s0 
-ended. Therefore, a„ embodiment ,ha, c„ me wi ,hi„ fte Kope ^ spjn , of fc 
followng Cairns and eouivaient ,here,o are claimed as ,he invention. 
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